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(57) ABSTRACT 

Authentication and session management can be used with a 
system architecture that partitions functionality between a 
human interface device (HID) and a computational service 
provider such as a server. An authentication manager execut- 
ing on a server interacts with the HID to validate the user 
when the user connects to the system via the HID. The 
authentication manager interacts with authentication mod- 
ules. Each authentication module may be configured to 
authenticate a user based on a different authentication 
mechanism (e.g., using a smart card, using a login and 
password, using biometric data, etc.) and may be utilized in 
connection with one or more sessions. The authentication 
manager and authentication modules are also responsible for 
controlling access to services/sessions and may remove/ 
revoke or augment such access. A session manager execut- 
ing on a server manages services running on computers 
providing computational services (e.g., programs) on behalf 
of the user. The session manager notifies each service in a 
session that the user is attached to the system using a given 
desktop machine. A service can direct display output to the 
HID while the user is attached to the system. When a user 
detaches from the system, each of the service's executing for 
the user is notified via the authentication manager and the 
session manager. Upon notification that the user is detached 
from the system, a service continues to execute while 
stopping its display to the desktop machine. 

21 Claims, 11 Drawing Sheets 




11/24/2003, EAST version: 1.4.1 



U.S. Patent 



Sep. 2, 2003 



Sheet 1 of 11 



US 6,615,264 Bl 




11/24/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 2 of 11 US 6,615,264 Bl 




11/24/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 3 of 11 US 6,615,264 Bl 




11/24/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 4 of 11 US 6,615,264 Bl 




11/24/2003, EAST version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 5 of 11 US 6,615,264 Bl 



416 



SEND START REQUEST 



418 



.4 



RETRY TIME = 
NOW + INTERVAL 



I 



.4 



420 



WAITING FOR STARTUP 



SEND STARTUP 
REQUEST 



INCREMENT MAXIMUM 
TRIES; RESET 
RETRY TIME 




422 



-YES- 



424 



426 



(?) 



© 



FIG. 4B 



11/24/2003, EAST version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 6 of 11 US 6,615,264 Bl 




11/24/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 7 of 11 US 6,615,264 Bl 



O 



r 



star 



1 



502 



identifier = 0 



504 



generate 128-bit 
random no. 



506 



send 

N_AUTHENTICATE 
and information packet 



1 



508 



send rendering 
commands 
prompting PIN entry 




reply - 



512 



identifier 
matches ' 




11/24/2003, EAST version: 1.4.1 



U.S. Patent 



Sep. 2, 2003 Sheet 8 of 11 



US 6,615,264 Bl 



send "Access denied, 

Remove Card" 
rendering commands 




526 



exit thread 



Yes- 



528 



send 

N_AUTHENTICATE 
Success 



i 



530 



send "Connecting to 
Session..." rendering 
commands 



532 



send address, port and 
sessionID to session 
manager host 



Figure 5B 



11/24/2003, EAST version: 1.4.1 



U.S. Patent 



Sep. 2, 2003 



Sheet 9 of 11 



US 6,615,264 Bl 



r 



start 



I 



602 



read in key strokes 
to <enter> or 
<return> 



604 



translate to ASCII 



606 



perform hmac_md5 on 
identifier+PIN+secret+challenge 



608 



send result as 
response to 
authentication server 




614 



D1U 

' — Yes T*C 




Yes- 



end 



Figure 6 



11/24/2003, EAST Version: 1.4.1 



U.S. Patent Sep. 2, 2003 



Sheet 10 of 11 



US 6,615,264 Bl 




11/24/2003, EAST version: 1.4.1 



U.S. Patent Sep. 2, 2003 Sheet 11 of 11 US 6,615,264 Bl 



^ 805 


CO 

o 

CO 




FLASH 




DRAM 











cc 
o 

CO 
CO 
LU 

o 
o 
cc 

Q_ 




11/24/2003, EAST version: 1.4.1 



US 6,6 

1 

METHOD AND APPARATUS FOR 
REMOTELY ADMINISTERED 
AUTHENTICATION AND ACCESS CONTROL 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates computer systems and, more 
specifically, to user authentication and the location manage- 
ment of user sessions. 

Portions of the disclosure of this patent document contain 
material that is subject to copyright protection. The copy- 
right owner has no objection to the facsimile reproduction 
by anyone of the patent document or the patent disclosure as 
it appears in the Patent and Trademark Office file or records, 
but otherwise reserves all copyright rights whatsoever. Sun, 
Sun Microsystems, the Sun logo, Java, and all Java-based 
trademarks and logos are trademarks or registered trade- 
marks of Sun Microsystems, Inc. in the United States and 
other countries. All SPARC trademarks are used under 
license and are trademarks of SPARC International, Inc. in 
the United States and other countries. Products bearing 
SPARC trademarks are based upon an architecture devel- 
oped by Sun Microsystems, Inc. 

2. Background Art 

The paradigms by which computer systems have been 
configured have changed over time. In earlier times, a 
computer consisted of a so called "mainframe" computer 
that was accessed by a plurality of "dumb terminals". The 
mainframe was a central station that provided computational 
power and data storage. A dumb terminal was a display 
device for data provided by the mainframe, and also pro- 
vided a means to communicate some data to the mainframe. 
Other system paradigms followed, including the desktop 
computer, client/server architecture, and recently, the 
so-called network computer. Using a dumb terminal 
paradigm, a user may switch from one terminal to another 
terminal. Each time a user switches a terminal, the user must 
be authenticated to work at new terminal. Various authen- 
tication mechanisms may be utilized such as a user name and 
password, biometric information (e.g., fingerprint or retinal 
scan), a smart card, etc. Different types of sessions need to 
be supported at different terminals by varying users. The 
prior art does not provide a satisfactory means to authenti- 
cate a user and control access to available network services/ 
sessions and terminals based on the authentication. 

A desktop computer is a self contained computing system 
where all applications and data are resident on the desktop 
computer system itself. Such systems were implemented in 
personal computers and have spurred the use of computers 
in homes and offices. A disadvantage of desktop computers 
is the short lifetime of the hardware used in the system. 
Desktop computers are microprocessor driven, and as faster 
and more powerful microprocessors become available, 
upgrades of existing desktop systems, or purchase of new 
desktop systems, is required. In many offices, there are 
personal desktop computers distributed throughout, some- 
times numbering in the thousands and tens of thousands. A 
disadvantage of such large systems is the lack of compat- 
ibility of applications and data on individual systems. Some 
users may have more recent versions of software applica- 
tions that are not backwards compatible with older versions 
of the software. The solution to this problem is to maintain 
consistent software on all systems. However, the cost to 
upgrade each system and to provide licensed copies of 
software and software upgrades can be substantial. 
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Client server systems are systems where central stores of 
data and/or applications are accessed through a network by 
personal computer clients. This provides some administra- 
tive efficiency in maintaining the shared data. However, the 

5 clients still have local applications and data that can present 
the same kinds of problems faced in the desktop systems 
already described. 

Recently, the rise of the internet has resulted in the 
proposed use of so-called "network computers". A network 

]0 computer is a stripped down version of a personal computer 
with less storage space, less memory, and often less com- 
putational power. The idea is that network computers will 
access data through the internet, and only those applications 
that are needed for a particular task will be provided to the 

15 network computer. When the applications are no longer 
being used, they are not stored on the network computer. 
There has been some criticism of such systems as lacking the 
power of a full desktop system, yet not being inexpensive 
enough to justify the reduced capability. And even though 

20 the network computer is a subset of a desktop computer, the 
network computer may still require upgrades of hardware 
and software to maintain adequate performance levels. 

An example of a dynamic host configuration protocol is 
provided in RFC 2131. RFCs 1321 and 2104 contain 

25 examples of MD5, or message digesting. A point to point 
challenge host authentication protocol is contained in RFC 
1994. 

Prior art mechanisms provide various means to authenti- 
cate a user. One prior art mechanism is referred to as 

30 kerberos. The kerberos system provides authentication over 
a network. To authenticate a user, registration in a kerberos 
database for each user is required. Once registered, a ticket 
is issued that contains an encrypted protocol message that 
provides authentication. Kerberos utilizes the ticket trans- 

35 parently to the user for network utilities such as NFS, rlogin, 
and rep. A ticket may have special privileges (e.g., for an 
administrator) and may expire after a specified period of 
time (e.g., 3 minutes). However, kerberos does not remove 
a user's session at the end of the time period, it will merely 

40 not allow a user to log back on once a user has disconnected. 
The ticket enables a user to present passwords to remote 
hosts without having to bother with remote files and login 
procedures. However, kerberos does not provide for access 
control features. 

45 Another prior art mechanism is referred to as PAM 
(pluggable authentication modules). PAM includes an inter- 
face library and multiple authentication service modules. 
The interface library is the layer implementing the applica- 
tion programming interface (API). The authentication ser- 

50 vice modules are a set of dynamically loadable objects 
invoked by the PAM API to provide a particular type of user 
authentication (e.g., smart card, user name and password, 
biometric data, etc.). PAM gives system administrators the 
flexibility of choosing any authentication service available 

55 on the system to perform authentication. New authentication 
modules can be plugged in and made available without 
modifying applications. PAM modules assume that the user 
being authenticated knows its identity and a password 
associated with that identity. Further, the PAM system is not 

60 concerned with and assumes that a communication port (that 
will be used to communicate with a user and conduct 
transmissions) is already established (e.g., the port is pre- 
configured for remote terminals and local consoles). 
Additionally, PAM relies on statically configured users and 

65 display devices (e.g., a server is preconfigured for each user 
and terminal). Once the number of users/terminals is known, 
a server is preconfigured for each server/user statically. The 
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configurations for a user/terminal are not performed dynami- system user and controlling access to services/sessions for a 

cally when requested. Further, once authenticated, PAM system user. In one embodiment of the invention, authenti- 

modules disappear and are no longer utilized. eating and access control are performed within a system 

architecture that partitions the computing functionality 

SUMMARY OF THE INVENTION 5 Detwecn a user's HID and a computational service provider 

Authentication and session management can be used with such as a server, 

a system architecture that partitions functionality between a FIGS. 1, 7, and 8 provide examples of system architec- 

human interface device (HID) and a computational service tures used in one or more embodiments of the invention. The 

provider such as a server. An authentication manager execut- present invention can be implemented in standard desktop 

ing on a server interacts with the HID to validate the user io computer systems such as described in FIG. 1, or in any 

when the user connects to the system via the HID. The other computer systems, including client-server systems, 

authentication manager interacts with authentication mod- network computers, or the human interface device system of 

ules. Each authentication module may be configured to FIGS. 7 and 8. 
authenticate a user based on a different authentication 

mechanism (e.g., using a smart card, using a login and 15 Embodiment of Computer Execution Environment 

password, using biometric data, etc.) and may be utilized in (Hardware) 

connection with one or more sessions. The authentication ^ embodimenl of lhe invenliorj can be implemented as 

manager and authentication modules are also responsible for computer x[tWiK m tbe form of compter readable code 

controlling access to services/sessions and may remove/ eX6cuUjd on a , ler such as ^ 

revoke or augment such access. A session manager execut- 20 m mustrated fa RG t or in ^ form of b ^ eoode dass 

ing on a server manages services running on computers files execulable wilbin a Java TM WDtime environment run- 

providing computational semces (e.g programs) on behalf nin such a m or io tbe form of byt e CO des running 

of the user. The session manager notifies each service in a 0Q , ^ (of devices enabled (Q ^ bytecodes) 

session that the user is attached to the system using a given cxistfa ^ a dislribuled cnvironmcm (e .g., one or more 

desktop machine. A service can direct d^play output to the 25 SS0I5 0Q , nelwork) . Akey board 110 and mouse 111 are 

HID while the user is attached to the system. When a user , ed , 0 a ffl bus m ^ ke ^ oard ^ mous£ are 

detaches from the system each of the service sexecuung for for introduci ^ ; t t0 the systern and 

the user is notified via the authentication manager and the communicating that ^ input lo processor 113. other 

session manager. Upon notification that the user is detached suilab , e m devices be used m addition Qr in lace 

from the system, a service continues to execute while 30 of> the mouse m ^ keyboard uo . , /0 (i n p U ^ 0U t P ut) unit 

stopping its display to the desktop machine. m coupkd tQ system bus m represents such I/0 elements 

BRIEF DESCRIPTION OF THE DRAWINGS as a printer, A/V (audio/video) I/O, etc. 

„_ , . . c . ... . , . Computer 100 includes a video memory 114, main 

FIG. 1 is an example of a system architecture used in one , . 

......... -.c memory 115 and mass storage 112, are coupled to system 

or more embodiments of the invention. , . ... . , , **,,_ , J 

bus lis along with keyboard 110, mouse 111 and processor 

FIG. 2 illustrates authentication and session management m ^ mass stQrage m may mclude both fixed and 

components and their interactions according to an embodi- removable mediaj such as mag netic, optical or magnetic 

ment of the invention. optical storage systems or any other available mass storage 

FIG. 3 provides a process flow for initializing a network 4Q technology. Bus 118 may contain, for example, thirty-two 

terminal in response to a power up operation according to an address lines for addressing video memory 114 or main 

embodiment of the invention. memory 115. The system bus 118 also includes, for example, 

FIGS. 4A-4C provide a process flow according to an a 64-bit data bus for transferring data between and among 

embodiment of the invention for initializing network termi- the components, such as processor 113, main memory 115, 

nal 202 in response to an awaken operation. 45 video memory 114 and mass storage 112. Alternatively, 

FIGS. 5A-5B provide an authentication process flow multiplex data/address lines may be used instead of separate 

according to an embodiment of the invention. data and address lines. 

FIG. 6 provides a challenge process flow according to an In one embodiment of the invention, the processor 113 is 

embodiment of the invention. a microprocessor manufactured by Sun Microsystems, Inc., 

FIGS. 7 and 8 provide examples of system architectures 50 such as the SPARC™ microprocessor, or a microprocessor 

used in one or more embodiments of the invention. manufactured by Motorola, such as the 680X0 processor, or 

a microprocessor manufactured by Intel, such as the 80X86, 
DETAILED DESCRIPTION OF THE or Pentium processor. However, any other suitable micro- 
INVENTION processor or microcomputer may be utilized. Main memory 
A method and apparatus for remotely administered 55 115 is comprised of dynamic random access memory 
authentication and access control services is described. In (DRAM). Video memory 114 is a dual-ported video random 
the following description, numerous specific details are set access memory. One port of the video memory 114 is 
forth in order to provide a more thorough description of the coupled to video amplifier 116. The video amplifier 116 is 
present invention. It will be apparent, however, to one used to drive the cathode ray tube (CRT) raster monitor 117. 
skilled in the art, that the present invention may be practiced 60 Video amplifier 116 is well known in the art and may be 
without these specific details. In other instances, well-known implemented by any suitable apparatus. This circuitry con- 
features have not been described in detail so as not to verts pixel data stored in video memory 114 to a raster signal 
obscure the invention. suitable for use by monitor 117. Monitor 117 is a type of 

monitor suitable for displaying graphic images. 
65 Computer 100 may also include a communication inter- 
Methods and apparatus are described according to one or face 120 coupled to bus 118. Communication interface 120 
more embodiments of the invention for authenticating a provides a two-way data communication coupling via a 
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network link 121 to a local network 122. For example, if interface device (HID). The partitioning of this system is 

communication interface 120 is an integrated services digital such that state and computation functions have been 

network (ISDN) card or a modem, communication interface removed from the HID and reside on data sources or 

120 provides a data communication connection to the cor- services. In one embodiment of the invention, one or more 
responding type of telephone line, which comprises part of 5 services communicate with one or more HIDs through some 
network link 121. If communication interface 120 is a local interconnect fabric, such as a network. An example of such 
area network (LAN) card, communication interface 120 a svslem * il^aled m FIG. 7. Referring to FIG. 7, the 
provides a data communication connection via network link svstem consists ° f computational service providers 700 

121 to a compatible LAN. Wireless links are also possible. g^^ ating daU thr ° Ugh mterconnecl fabnc 701 to 
In any such implementation, communication interface 120 10 _ . . IIir4 

sends and receives electrical, electromagnetic or optical Computational Serv.ce Providers-In the HID system, 
.... . , . . . & r . the computational power and state maintenance is found in 
signals which carry digital data streams representing various t . t . , r ™_ . , , 
f • r * tne service providers, or services. The services are not tied 
types ot information. lo g specific comp^ but may be distributed over one or 
Network link 121 typically provides data communication more traditional desktop systems such as described in con- 
through one or more networks to other data devices. For 15 neclion witb F IG. 1, or with traditional servers. One corn- 
example, network link 121 may provide a connection puter may have one or more services, or a service may be 
through local network 122 to local server computer 123 or implemented by one or more computers. The service pro- 
to data equipment operated by an Internet Service Provider v j dcs computation, state, and data to the HIDs and the 
(ISP) 124. ISP 124 in turn provides data communication service is under the control of a common authority or 
services through the world wide packet data communication 20 manager> [ n pic 7, the services are found on computers 710, 
network now commonly referred to as the "Internet" 125. m 7^ 713 and 714. 

Local network 122 and Internet 125 both use electrical, Examples of services include Java™ program execution 
electromagnetic or optical signals which carry digital data X U/Unix services, archived video services, Win- 
streams. The signals through the various networks and the dows m servicCj and Qlhers A service hcrdn ^ a process 
signals on network link 121 and through communication 25 ^ ides ompul daU and rosponds l0 uscr rcquests and 
interface 120, which carry the digital data to and from input 

computer 100, are exemplary forms of carrier waves trans- , ^ • r u - 1 .u ■ *u - . 

• . h ■ J- Interconnection Fabric — In the invention, the mtercon- 

porting the intormation. nection fabric is any of multiple suitable communication 

Computer 100 can send messages and receive data, paths for carrying data between the services and the HIDs. 

including program code, through the networks), network In one embodiment the interconnect fabric is a local area 

link 121, and communication interface 120. In the Internet ne twork implemented as an Ethernet network. Any other 

example, remote server computer 126 might transmit a local network may also be utilized. The invention also 

requested code for an application program through Internet contemplates the use of wide area networks, the internet, the 

125, ISP 124, local network 122 and communication inter- world wide webj and others The interconnect fabric may be 

face 120. In accord with the invention, one such downloaded implemented with a physical medium such as a wire or fiber 

application is the apparatus for selecting attachments optic cabk> 0f it may be impleiri emed in a wireless envi- 

desenbed herein. ronment. 

The received code may be executed by processor 113 as HIDs— The HID is the means by which users access the 

it is received, and/or stored in mass storage 112, or other ^ computational services provided by the servers or services, 

non-volatile storage for later execution. In this manner, and as sucn lbe HID may also be referred to as a client or 

computer 100 may obtain application code in the form of a user workstation or terminal. FIG. 7 illustrates HIDs 721, 

carrier wave. 72 2, and 723. A HID consists of a display 726, a keyboard 

Application code may be embodied in any form of 724, mouse 725, and audio speakers 727. The HID includes 
computer program product. A computer program product 45 the electronics need to interface these devices to the inter- 
comprises a medium configured to store or transport com- connection fabric and to transmit to and receive data from 
puter readable code, or in which computer readable code the services. 

may be embedded. Some examples of computer program A biock diagram of the HID is illustrated in FIG. 8. The 

products are CD-ROM disks, ROM cards, floppy disks, components of the HID are coupled internally to a PCI bus 

magnetic tapes, computer hard drives, servers on a network, 5Q 812. A network control block 802 communicates to the 

and carrier waves. interconnect fabric, such as an ethernet, through line 814. An 

The computer systems described above are for purposes audio codec 803 receives audio data on interface 816 and is 

of example only. An embodiment of the invention may be coupled to block 802. USB data communication is provided 

implemented in any type of computer system or program- on lines 813 to USB controller 801. 

ming or processing environment. 55 An embedded processor 804 may be, for example, a 

„ . - ~ • ~ o Sparc2ep 804 with coupled flash memory 805 and DRAM 

Human Interface Device Computer System 8Q6 ^ USB m Qetwork gQ2 and 

The invention also has application to a computer systems embedded processor 804 are all coupled to the PCI bus 812. 

where the data to be displayed is provided through a Also coupled to the PCI 812 is the video controller 809. The 

network. The network can be a local area network, a wide 60 video controller 809 may be for example, and ATI Ragel28 

area network, the internet, world wide web, or any other frame buffer controller (or any other suitable controller) that 

suitable network configuration. One embodiment of the provides SVGA output on line 815. NTSC or PAL data is 

invention is used in computer system configuration referred provided into the video controller through video decoder 

to herein as a human interface device computer system. 810. A smart card interface 808 may also be coupled to the 

In this system the functionality of the system is parti- 65 video controller 809. 

tioned between a display and input device, and data sources Alternatively, the HID can be implemented using a single 

or services. The display and input device is a human chip solution including the necessary processing capability. 
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This architecture or system is described in greater detail 
in U.S. patent application Ser. No. 09/063,335, assigned to 
the present assignee, filed Apr. 20, 1998, entitled "Method 
and Apparatus for Providing a Virtual Desktop System 
Architecture" which is hereby fully incorporated by refer- 
ence. 

The computer systems described above are for purposes 
of example only. An embodiment of the invention may be 
implemented in any type of computer system or program- 
ming or processing environment. 

In one or more embodiments of the invention, authenti- 
cation and session management components are configured 
to authenticate users and control access to services/sessions. 
A session is a persistent representation of a related set of one 
or more services executing on behalf of a user. Embodiments 
of the invention authenticate a user and relocate a user's 
session based on the current location of the user without 
requiring a service within a session to be configured to 
perform user validation and relocation. One or more 
embodiments of the invention authenticate the user once for 
all of the user's services. Other embodiments of the inven- 
tion may require reauthentication or a new authentication 
depending on the service utilized. Using embodiments of the 
invention, services are directed to the HID (or other terminal 
device) that a user is currently using. It is not necessary for 
the user to login to each service and establish a new 
connection for a specific HID. Using embodiments of the 
invention, the use of a particular service may also be 
terminated if desired. For example, after a designated time 
period, a user's authentication may no longer be valid and 
such invalidity may act to terminate a session. Alternatively, 
a user may be requested to reauthenticate themselves every 
so often to ensure only authorized users are permitted 
access. Should a reauthentication attempt fail, a session may 
be terminated immediately. 

According to embodiments of the invention, authentica- 
tion is a one-way authentication which improves the man- 
ageability and scalability of authentication. There is no need 
to exchange keys and avoids the need to perform key 
lookups in a central database. 

FIG. 2 illustrates authentication and session management 
components and their interactions according to an embodi- 
ment of the invention. Network terminal 202 is a human 
interface device (HID) (e.g., HIDs 821, 822 and 823). An 
HID has, as examples of its functions, the task of displaying 
output of services to a user and obtaining input to services 
from the user. Network terminal 202 has the ability to 
respond to a command (e.g., display command) received 
from, for example, a software program (e.g., services 
230-238, authentication manager 204 and session manager 
206) executing on a computational service provider (e.g., 
computers 710, 711, 712, 713, and 714). The input received 
from a user is forwarded to, for example, a service that is 
fulfilling a user request. 

More than one server can execute the services that com- 
prise a session. For example, in session 208, service 230 is 
executing on server 210, services 232 and 234 are executing 
on server 212 and services 236 and 238 are executing on 
server 214. 

A user may access a system (e.g., a server, a session, a 
service and a network terminal) by initiating a login or other 
authentication mechanism (e.g., smart card, biometric data, 
etc.). A separate authentication module 240 may be utilized 
for each authentication mechanism. During login, the user is 
validated by an authentication module 240. The authentica- 
tion modules 240 communicate with authentication manager 



L5,264 Bl 

8 

240 where a user may be associated with a particular 
session. Various techniques can be used to allow the user to 
initiate a login. For example, the user can initiate a login by 
pressing a key on network terminal 202. Further, a terminal 

5 202 may have screen display icons that allow a user to 
determine the progress of the authentication process. 

In one embodiment of the invention, a user accesses the 
system by inserting a smart card in a card reader (e.g., card 
reader 216) attached to network terminal 202. A smart card 

1Q is a card that is capable of storing information such as in a 
magnetic strip or memory of the smart card. The smart card 
can store user information such as a user's identification 
(i.e., user ID such as a 64-bit number) and a secret code (e.g., 
a 128-bit random number) that is transmitted to network 
terminal 202. The secret code is used during authentication 
by a smart card authentication module, for example. 

Network terminal 202 is aware of (or can obtain) its 
interconnection network address and the address of authen- 
tication manager 204. When a user initiates the login, 

2 0 network terminal 202 initiates communication with authen- 
tication manager 204 to begin authentication. Authentication 
manager 204 is a program active (e.g., executing) on a 
computational service provider connected to network termi- 
nal 202 via an interconnection network such as a local area 

25 network (LAN), for example. It should be apparent, 
however, that network terminal 202 can be connected to 
authentication manager 204 using other interconnection 
network technologies such as a fiber channel loop or point- 
to-point cables. Network terminal 202 sends a startup 

30 request to authentication manager 204 that includes a unique 
identifier that may correspond to a user. Such an identifier 
may originate from a token (a particular message or bit 
pattern that signifies permission to transmit information) or 
a pseudo token. For example, tokens may be encoded into 

35 smart cards and when a smart card is inserted in a card reader 
at a terminal, the token is transmitted from the terminal 202. 
Alternatively, a token may be created by a fingerprint reader 
or other external device. If a smart card is not inserted, or a 
token is not presented at terminal 202, terminal 202 may 

40 construct a "pseudo token" and transmit the pseudo token to 
authentication manager 204. A pseudo token may be iden- 
tified by the type associated with it (e.g., "pseudo") and a 
network interface address such as an ethernet address or a 
media access controller (MAC) address. 

45 To initiate a connection, a network terminal 202 may be 
booted up. Once booted, terminal 202 may utilize a dynamic 
host configuration protocol (DHCP) to obtain application 
parameters such as the internet protocol address. Terminal 
202 then establishes a connection with authentication man- 

50 ager 204 (e.g., using TCP). To establish a connection, 
terminal 202 may send a message or present a token to the 
authentication manager 204. Authentication manager 204 
then determines whether it wants to take responsibility for 
this particular terminal/user. In one or more embodiments, 

55 authentication manager 204 presents the message (with the 
token) to one or more authentication modules 240. 

Authentication modules 240 each have the option of 
accepting or declining responsibility for a particular con- 
nection. Authentication modules 240 may base their deci- 

60 sion on other available system resources or settings (e.g., 
from services 230-238, external databases, etc.). In one or 
more embodiments, an authentication module 240 can be 
configured to accept all users all of the time, to only accept 
connections with smart cards, or to only accept users with 

65 pseudo tokens, for example. 

In one or more embodiments, authentication modules 240 
may be cascaded and a message may pass from one module 
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to another module until responsibility is accepted. Thus, to a particular user. The registration application may then 

when an authentication module 240 declines responsibility terminate. Thus, the next time a token is presented to the first 

for a particular connection, the message may be passed onto authentication module, the token is present and registered 

another authentication module 240. Modules 240 may be with the system so that the first authentication module may 

ordered such that the first time responsibility is claimed, all 5 take responsibility for the token/message. Using this 

"lower" modules do not apply. Alternatively, modules 240 embodiment, users update a registration database instead of 

may be stacked and multiple modules may be utilized or relying on an administrator to manually update information 

required in one connection. If all modules decline each time a new user is added to a system. Thus, authenti- 

responsibility, access may be denied. If a module 240 cation manager 204 is responsible for passing messages onto 

decides to accept responsibility, various generic services 1Q authentication modules 240, for denying or allowing access 

may be provided to modules 240 by authentication manager to a session, and if allowing access, determining what type 

204. For example, authentication manager 204 may provide of session to present to terminal 202. 

authentication module 240 with a start session service (a \ a one or more embodiments of the invention, once 

procedure that ensures a session is started (see further authenticated, the authentication modules may remain active 

description below)). Additionally, the module 240 has the J5 anc j ensure that the authentication maintains a proper state, 

option of further communicating with terminal 202. For p or example, authentication may be time sensitive (e.g., 

example, module 240 may challenge the user using a ft om 9 A.M. to 5 P.M.) and once the specified time has 

challenge-response routine or request a secondary password. expired, an authentication module 240 may revoke the 

Authentication modules may be structured for any mecha- authentication and a session may be terminated, 

nism that verifies the identity of the user to the system. A key 2Q Alternatively, an authentication module 240 may require 

or password known only to the user, or biometrics in forma- reauthentication from a user at random times. For example, 

tion can be used to authenticate the user. For example, one if a user is at a terminal 202 that requires payment every 10 

authentication module may be utilized to authenticate a user minutes, an authentication module 240 may debit a cash card 

based on a smart card while another authentication module every 10 minutes until the cash card is empty at which point 

may be utilized to authenticate a user based on a key or 25 a session may be removed/revoked from display on terminal 

password or biometrics information. 202. In another use, a teacher in a classroom may validate 

In one or more embodiments of the invention, aulhenti- student's terminals for one hour to view a preconfigured set 

cation is performed by verifying a personal identification of internet sites. After an hour, authentication modules 240 

number (PIN) entered by the user at network terminal 202 by may remove/revoke each student's display of the session, 

an authentication module 240. An authentication module 30 If the expected result is received from the user (i.e., 

240 sends a command (i.e., a challenge command) to initiate authentication module 240 has authenticated a user), authen- 

entry of the user's PIN at network terminal 202. The user tication module 240 informs authentication manager 204 of 

entry is packaged by network terminal 202 and transmitted the authentication. Authentication manager 204 or authen- 

to authentication module 240 (i.e., a challenge response). tication module 240 may then use a start session service to 

Authentication module 240 verifies the challenge 35 ensure a session is currently running. Once a session is 
response with user information retained in authentication established, terminal 202 is connected to the session. To 
database 218, for example, information supplied by the user establish a connection to a session, authentication manager 
and information that is generated during authentication. 204 notifies session manager 206 (via a connect message) 
When the user is authenticated, the user eventually be given that the user has logged into the system on network terminal 
access to a session (e.g., session 208). Through the user 40 202. Session information contained in authentication data- 
authentication process, authentication modules are able to base 218 may be used to identify the server, port and session 
establish a communication port through which future trans- identifier (ID) for session manager 206. Session manager 
missions will be conducted with terminal 202. Thus, authen- 206 is a program that is active on a computational service 
tication modules 240 are concerned with both the wiring to provider and is connected to authentication manager 204 and 
a terminal to establish a port and authenticating a user 45 network terminal 202 via an interconnection network, for 
utilizing that port. example. Thus, as described, authentication manager 204 

In one or more embodiments, two authentication modules sends a message to session manager 206 using session 
may be utilized. In such an embodiment, when a token or manager 206's server and port information contained in 
smart card is inserted at terminal 202, terminal 202 sends a authentication database 218, for example. As a result, 
message to authentication manager 204. Authentication 50 authentication manager 204 dynamically configures a net- 
manager 204 presents the message to the first authentication work terminal for a particular service (e.g., services 
module 240. The first authentication module 240 looks up 230-238). In one or more embodiments of the invention, 
the token in a database to determine if the token is registered authentication modules 240 may annotate a session based on 
with the system. If not (i.e., the first authentication module the authentication and a behavior can be modified based on 
does not want to accept responsibility for the token/ 55 the annotation. For example, a module 240 may annotate a 
message), the first authentication module passes the token/ session such that a user is authenticated based on a finger- 
message onto a second authentication module. The second print and subsequent authentication modules can use that 
authentication module may be configured to accept all annotation. 

tokens/messages. Once the token is received, the second In response to the connect message from authentication 

authentication module may initiate a registration session and 60 manager 204, session manager 206 notifies the services in 

inform the session manager to connect the session to the the user's current session (i.e., the services in session 208) 

terminal issuing the request. The registration application that the user is attached to network terminal 202. That is, 

presents a form interface to the user where information session manager 206 sends a connect message to services 

regarding the user may be obtained (e.g., a username and 230-238 to direct output to network terminal 202. Session 

password or biometric data). Once the information is 65 manager 206 ensures that services that are considered to be 

received, the information about the user and the token may required services of the session are executing. If not, session 

be stored in a database. Consequently, a token may be bound manager 206 causes them to be initiated. The user can 
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interact with services 230-238 within a session (e.g., session the user. As described below, a session can have none or 

208). Network terminal 202 is connected to servers 210, 212 more required services. It may be necessary to initiate some 

and 214 (and services 230-238) via an interconnection of the required services when the session is created. Once a 

network such as a local area network or other interconnec- service is initiated, it continues to be active regardless of 

tion technology. The user can also start new services or 5 whether the user is connected to the system. The balance of 

terminate existing services. For example, if a login service/ required services can be initiated when the user first logs in. 

session (e.g., a service that prompts a user for a login) has A user is not limited to one session. There can be multiple 

been running for a certain period of time without a user sessions associated with a user at any given time. Session 

entering the useraame and password (e.g., it is annotated as database 220 contains records that identify the session(s) 

idle for a certain period of time), the login service may be 10 and service(s) within a session that are associated with a 

terminated. Once a user desires to enter a username and user. An enabled user can be removed from the system (e.g., 

password (e.g., by depressing a key on the keyboard), a new w h en an authentication module 240 determines that a user is 

login session may be initialed and annotated as not idle. n o longer authentic (e.g., time limit has expired)). When a 

The user can detach from the system by removing the card user is removed from the system, all of the user's associated 

from card reader 216. Other mechanisms to express a 15 sessions are removed from the system and from session 

disconnect can also be used with the invention (e.g., a database 220. Services associated with the user's sessions 

"sign -off button on network terminal 202). Services are stopped as well. 

230-238 can continue to run even after the user removes the Once a user is enabled to use a system, the user can log 

card from card reader 216. That is, a user's associated onto t h e system via network terminal 202. When session 

session(s) and the services that comprise a session can 20 manager 206 is notified by authentication manager 204 that 

continue in existence during the period that a user is unat- t h e user is connected to network terminal 202, session 

tached (e.g., logged off) from the system. When the user manager 206 notifies the user's session (i.e., the services that 

removes the card from card reader 216, network terminal comprise a session). Session manager 206 consults session 

202 notifies authentication manager 204 (e.g., via a discon- database 220 to identify and notify the session's services, 

nect message) which notifies session manager 206 (e.g., via 25 Fof example) session database 220 includes information that 

a disconnect message). Session manager 206 notifies ser- identifies session 208 and services 230-238 that are included 

vices 230-238 (e.g., via a disconnect message) which ter- [ n session 208. 

minate their transmission of display commands to network ^ Qr mofe embodimentSj session database 220 may 

terminal 202. Services 230-238 continue execution, acliye and associated tokens 

however, during the time that the user is not logged onto a 30 Co eml tf autnenticalion manager 2 04 dies or is 

network terminal. T^e user can log back in using a network ^ shm d aU sessions be disoranfiCtcd . 

terminal such as network terminal 202 connect to session Howcvcr once auth entication manager 204 is started back 

208 and interact with services 230-238. up> scssfon database 22Q may ^ to reconstruct 

While FIG. 2 depicts a single instance of each, it should connections between sessions and the associated tokens. In 

be apparent that there can be multiple instances of network 0 ne or more embodiments, an additional database may be 

terminal 202, authentication manager 204, authentication utilized that contains a mapping between a user identity, 

modules 240, and session 208. For example, there can be tokens, sessions, and associated permissions. Such a data- 

more than one instance of authentication manager 204 base provides information regarding whether a token is 

servicing network terminal 202 or multiple instances of a lbwed access or not to a particular session and what type 

network terminal 202. Authentication manager 204 0 f session or particular services may be utilized by a 

instances can be organized in a hierarchy according to the particular token. Thus, varying tokens may have different 

topology of the network or they can be globally available, levels of access associated with the token. For example, one 

for example. token may provide the ability to use an internet browser 

Having more than one instance of the authentication 45 application, while another token may provide unlimited 

manager improves the scalability of the system since it is access to all resources on the network, and another token 

possible to add (or remove) instances of authentication may provide access to a certain desktop organization or 

manager 204 based on the current load (e.g., the number of architecture. 

users). Further, reliability is improved since redundant j n one or more embodiments, a different database type 

instances of authentication manager 204 can be deployed. 5Q may ex i st f or eac h au thentication module 240. Alternatively, 

Similarly, there can be a multiplicity of session manager one module 240 may utilize several database types. Such 

206 instances. Like authentication manager 204, multiple databases may be in a format consisting of key-value pairs, 

instances of session manager 206 can increase the scalability a table, or tabular. 

and reliability of the system. I n one or more embodiments, session database 220 con- 
Session Mana er 55 tams P ermanent session records and dynamic session 
s records that identify sessions and the services associated 

Session manager 206 maintains session database 220 that with a session. Session database 220 can be one or more 

contains mappings between users, sessions, and services. databases or data stores. For example, permanent session 

Session manager 206 manages the services that comprise records can be stored in a configuration file while dynamic 

each session managed by session manager 206. For eo session records can be stored in memory in a database 

example, session manager 206 maintains session 208 and system. A permanent session record contains configuration 

services 230-238 within session 208. information for a user and is typically created for a user at 

To access a computational service provider, an account is the time the user is enabled to use the system, for example, 

first set up or enabled for a user. For example, to enable a A dynamic session record identifies those services that are 

user according to one embodiment of the invention, the user 65 associated with a user. Dynamic session records identify the 

is given a userlD, a PIN and a smart card that stores the required services that are associated with a user session in a 

userlD and secret code. In addition, a session is created for permanent session record as well as currently active ser- 
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vices. The following contains a formal for a permanent 
session record according to an embodiment of the invention: 
sessionID servicelD serviceHost servicePort isLazy 
The sessionID field uniquely identifies the session that 
contains the required service(s). The servicelD field 5 
uniquely identifies a service associated with the session 
identified by sessionID. The serviceHost and servicePort 
fields identify the server on which a service is running and 
the port on the server by which a service can receive 
communications. The isLazy field identifies the manner in 30 
which a service is initiated. For example, isLazy can specify 
that the service is to be started immediately upon the 
creation of a session, or that the service is to be started when 
the user first accesses the system. There may be multiple 
occurrences of the servicelD, serviceHost, servicePort and 3S 
isLazy fields each occurrence identifying a required service 
associated with the session identified by sessionID. 

The dynamic session record identifies the required ser- 
vices for the session and those services that are currently 
executing in the session. A session's required services are 2 o 
retrieved from the permanent session record, for example. A 
dynamic session record can identify zero or more services 
(required or otherwise) that are currently executing on 
behalf of a user. 

The fields that are used to store information about a 2 s 
service in a dynamic session record depends on whether the 
service is a required service or a service. A required service 
that is currently active is also a current service. The format 
of a dynamic session record that identifies a session's 
required services is the same as the permanent session 3 q 
record format. The following identifies the format for a 
record associated with a currently executing service accord- 
ing to an embodiment of the invention: 

sessionLink TCPSocketfd requiredServiceLink servicelD 
The sessionLink field identifies the service's session. An 35 
open connection, or pipe, is established between session 
manager 206 and a currently executing service in a session., 
The open connection can be used to notify either session 
manager 206 or the service that the other has abnormally, or 
otherwise, terminated. In one embodiment of the invention, 40 
the open connection is a TCP socket connection which is 
identified by the TCPSocketfd field. However, it should be 
apparent that any form of reliable connection technology 
that could provide a notification that a connection is disabled 
or disappears could be used with embodiments of the 45 
invention. 

The service has an identifier that is stored in the servicelD 
field. A currently running service can be linked to a required 
service. A link to a required service is identified by the 
requiredServiceLink. If there is no link to a required service, 50 
the requiredServiceLink is null. 

The dynamic session record can also be used to store 
information about a connection to a network terminal (e.g., 
network terminal 202). The following contains the fields that 
identify the connection according to an embodiment of the 55 
invention: 

sessionLink Status IPAddress 

Multiple sessions can be associated with a user. The 
sessionLink field identifies the session to which the user 
attached to network terminal 202 is currently linked. The 60 
sessionLink can have as its value the sessionID value, for 
example. The status field identifies the connection status 
(i.e., connected or disconnected) of network terminal 202 to 
the session. The IPAddress field contains the interconnection 
network address of network terminal 202. An IP address is 65 
used in one or more embodiments of the invention. 
However, it should be apparent that alternative interconnec- 
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tion technologies may use alternate addressing schemes. For 
example, an asynchronous transfer mode (ATM) network 
might use a thirteen digit switch prefix/end point identifier. 

This information can be used by session manager 206 to 
send a status message to network terminal 202. If network 
terminal 202 does not respond within a certain period of 
time, session manager 206 assumes that network terminal 
202 is no longer in use by the user and sends a disconnect 
message to each of the services in the session. 

Other information of which session manager 206 is aware 
include a list of the open connections (e.g., services having 
an open TCPsocketfd) to services and a mapping between 
open connections and sessions and the services within a 
session. This information can be compiled from the session 
records, for example. 

The information available to session manager 206 can be 
used to locate a session. For example, given a service, it is 
possible to find a session that contains the service and/or the 
services that are contained within a session. Further, it is 
possible to locate a session that is associated with a given 
user or instance of network terminal 202 whether or not it is 
currently executing, for example. 
Service Initiation 

When session manager 206 receives a message from 
authentication manager 204 that a user is connected to 
network terminal 202 (and has been authenticated by an 
authentication module 240), session manager 206 initiates 
those required services that are not currently active. Session 
manager 206 further notifies the currently active services to 
direct input/output (I/O) to network terminal 202. I/O can be 
expressed using a command protocol used to communicate 
with network terminal 202 and its peripheral devices. 

To initiate a service, session manager 206 accesses the 
server on which the service is to execute to start the service. 
For example, session manager 206 sends a request to a 
well-known port on the server and passes the sessionHost, 
sessionPort and sessionID for session manager 206. The 
server connects to network terminal 202 that is attached to 
the service and uses the server's native authentication and 
permissions to allow the user to access the server. For 
example, in a UNIX operating environment, a UNIX service 
could start with a "CDE Login" screen displayed at network 
terminal 202 to authenticate the user and ensure that the user 
wishes to connect to the service. 

For session manager 206 to start a service on a server, it 
is given the privileges needed to start the service. It may be 
undesirable to give session manager 206 these privileges. 
Further, in current networking environments, servers may be 
running different operating environments. In this case, ses- 
sion manager 206 must be aware of each operating envi- 
ronment's procedures for initiating a service. 

Alternatively, a session-aware application running on the 
server can perform the initiation and register the service with 
session manager 206. In this case, it is not necessary for 
session manager 206 to have the needed privileges. Further, 
session manger 206 does not have to implement a central- 
ized model for initiating services on multiple operating 
environments. The responsibility for initiating services is 
left to the session -aware applications that are running in the 
different operating environments. A session-aware server 
application has knowledge of session manager 206 (e.g., has 
the sessionID, sessionHost and sessionPort of session man- 
ager 206) and its interfaces (e.g., message formats). 

The session-aware server application can initiate a service 
in response to a request received from session manager 206. 
Session manager 206 sends an initiate message to the server 
application that possesses the permission to start services in 
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the server's operating environment. The server application 
initiates the service for session manager 206 and responds to 
session manager 206 with a valid sessionlD. On the UNIX 
and NT systems, for example, the sessionlD can be made 
available in the operating environment. Services such as 5 
video windows might start in this manner, for example. 

Alternatively, the session-aware application can contact a 
service to obtain its permission in the form of a crypto- 
graphically signed authorization. The server application can 
transmit the sessionlD and the signed authorization to ses- 10 
sion manager 206, If the session-aware application contacts 
session manger 206 without an authorization but with a 
description of the service, session manager 206 could 
request approval from network terminal 202 to ensure that 
the user authorized the service. If the user responds is 
affirmatively, the service is added to the session. In one or 
more embodiments of the invention, authentication modules 
240 are responsible for controlling access to one or more 
sessions. Consequently, an authentication module 240 may 
authenticate a user for a particular session or multiple 20 
sessions depending on the privileges specified in the authen- 
tication module 240. 
Session Manager Messages 

Session manager 206 receives and generates messages to 
manage the services within a session. Techniques other than 25 
those described herein can be used for initiating services. If 
session manager 206 initiates a service, it sends an initiate 
message to the server (or session-aware server application). 
Session manager 206 can generate an initiate message to 
start required services identified in session database 220, for 30 
example. As another example, session manager 206 can send 
an initiate message to re-activate a required service that it 
has determined (e.g., via an open TCP connection between 
session manager 206 and the service) has terminated. 

Session manager 206 receives a connect message when a 35 
user of network terminal 202 successfully attaches to the 
system. In response to the connect message, session man- 
ager 206 verifies that all of the required services are started, 
and starts those that are not running. Session manager 206 
sends a message (e.g., a connect message) to the services in 40 
the session to direct I/O to network terminal 206. 

In one or more embodiments, session manager 206 moni- 
tors the status of sessions and can determine when there are 
no longer any active sessions. For example, if an embodi- 
ment utilizes two authentication modules (as described 45 
above), session manager 206 detects when the registration 
application/session is finished since no sessions are active. 
Session manager 206 transmits a message to authentication 
manager 204 indicating that the number of sessions are 
empty. Authentication manager 204 determines whether to 50 
terminate the connection with the terminal. A determination 
to terminate the connection causes terminal 202 to reevalu- 
ate the state of the tokens that have been presented to 
terminal 202. Terminal 202 may then resubmit any currently 
presented tokens to authentication manager 204 to start the 55 
process over again. 

In one or more embodiments, when a disconnect message 
is received, session manager 206 sends a disconnect mes- 
sage to each one of the services in the session directing them 
to terminate sending I/O to network terminal 202. 60 

Session manager 206 can send status messages to network 
terminal 206 periodically to ensure that network terminal 
202 is still connected. For example, session manager 206 
can examine session database 220 's dynamic session records 
to identify each session that is currently connected to a 65 
network terminal. That is, session manager 206 can examine 
the status field associated with a network terminal in a 
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dynamic session record in session database 220. Session 
manager 206 sends a status request (e.g., a "ping") to each 
network terminal that is connected with a session. If an 
answer is not received from network terminal 202 within a 
certain period of time (e.g., 20 seconds) for a particular 
session, session manager 206 assumes that the session is 
disabled and it sends a disconnect message to each service 
in the session instructing them to terminate display func- 
tions. In one or more embodiments, a UDP protocol is 
utilized to transmit a status request and receive a response. 

Network terminal 202 responds to the status (e.g., ping) 
request from session manager 206 with either a "Card In" or 
"Card Out" status. If a "Card Out" status is received from 
network terminal 202, session manager 206 sends a discon- 
nect message to each of the session's services. 

If the "Card In" status is sent in response to a status 
request, network terminal 202 also indicates the number of 
insertions of the card in card reader 216, the number of 
seconds since a card insertion, and the cardlD. The cardID 
is, for example, the value of sessionlD for the user's session. 
Session manager 206 retains at least the last status informa- 
tion received from network terminal 202 to compare the new 
status information against the previous status information. 
If, for example, the number of insertions or the number of 
seconds for insertion differs from the last status information, 
session manager 206 considers the session to be disabled. In 
this case, session manager 206 sends a disconnect message 
to the session's services. 

In one or more embodiments of the invention, session 
manager 206 does not ping terminals. In such an 
embodiment, a TCP/IP protocol may be utilized (a protocol 
that is more reliable than UDP) to transmit messages 
between terminal 202 and session manager 206. Due to the 
reliability of the TCP/IP protocol (transmission control 
protocol/internet protocol), a message sent from either ter- 
minal 202 or session manager 206 only needs to be sent 
once. As long as the connection between the terminal 202 
and session manager 206 remains active, the presence or 
absence of a token (e.g., when a card is removed or a user 
logs out) may cause a "Token Inserted" message (similar to 
a "Card In" message) or "Token Remove" message (similar 
to a "Card Out" message) to be transmitted from terminal 
202 to session manager 206. Once such a message is 
transmitted to session manager 206, session manager 206 
may transmit a disconnect message to the session's services. 

In one or more embodiments of the invention, authenti- 
cation modules 240 may remain active and monitor the 
authentication state of a user or terminal. For example, when 
a card is removed, a smart card authentication module may 
remove or revoke access to sessions associated with the 
card. Further, as described above, authentication modules 
may periodically re authenticate a user/terminal (e.g., by 
requesting a user name and password again, by requesting a 
fingerprint again, etc.). 

When a service is started by, for example, a session-aware 
server application, a service connect message is sent to 
session manager 206. If the service has the proper 
authorization, session manager 206 adds the service to the 
list of services for the session and sends a message to the 
service to direct I/O to network terminal 202. 

Authentication Manager 

The authentication manager and authentication modules 
are responsible for ensuring the legitimacy of a user and 
associating/controlling access to a session(s) for a user. 
During the initialization process (which is described in more 
detail below), a port to communicate with a terminal is 
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established and an authentication exchange takes place to 
authenticate the user in one embodiment of the invention. 
Authentication can include any mechanism that verifies the 
identify of the user to the system. For example, a key 
password can be entered or biometrics data can be collected 5 
to authenticate the user. 

Authentication database 218 contains user and session 
information that can be accessed by authentication manager 
204 or authentication modules 240. In one embodiment of 
the invention, the format of a record contained in authenti- 30 
cation database 218 is as follows: 

user ID secret PIN sessionHost sessionPort sessionID 

The userlD and secret fields contain the same values as 
those stored in a user's smart card. The userlD and secret 
values are typically established when the user is enabled to 15 
use the system, for example. In one embodiment of the 
invention, the secret field contains a 128-bit value. The PIN 
field is the personal identification number (PIN) that is 
known to the user and requested by an authentication 
module 240 during authentication. The userlD, secret and 20 
PIN values are used to authenticate a user. Authentication 
database 218 could contain other information such as a 
password or biometrics data, if they were used to authenti- 
cate a user. Alternatively, authentication modules 240 may 
store the information instead of authentication database 218. 25 

The sessionHost field identifies the computational service 
provider (e.g., a server) that is executing session manager 
206 that is managing the user's current session. The ses- 
sionPort field identifies the port (as established by an authen- 
tication module 240) for communicating with session man- 30 
ager 206. The sessionID field contains a unique identifier for 
session manager 206. If authentication is successful, the 
sessionHost, sessionPort and sessionID fields are used to 
notify session manager 206 of the user's location at the 
network terminal 202. Further, authentication modules 240 35 
are responsible for establishing and setting the port in 
authentication database 218. 

In an embodiment of the invention, a challenge mecha- 
nism may be used to authenticate a user. (FIG. 6 provides a 
challenge process flow according to an embodiment of the 40 
invention.) Authentication module 240 sends a challenge to 
network terminal 202 to verify the authenticity of the user. 
Network terminal 202 prepares the challenge response, and 
returns it to authentication module 240. If the response to the 
challenge is as expected, the user is verified to authentication 45 
module 240. Authentication module 240 communicates with 
authentication manager 204 that communicates with session 
manager 206. 

FIGS. 5A-AB provide an authentication process flow 
according to an embodiment of the invention. The authen- 50 
tication process can be repeated more than once until 
authentication is successful or the number of repetitions, or 
rounds, exceeds a certain number. At step 502, an identifier 
that represents the number of the authentication round is 
initialized to zero. At step 504, a random number is gener- 55 
ated that is used as the challenge number. At step 506, 
authentication module 240 sends an N__AUTHENTI CATE 
command to network terminal 202 as well as a packet of 
information for the authentication process. 

In one embodiment of the invention, the following infor- 60 
mation is sent in conjunction with the 
N_AUTHENTICATE command: 

code identifier length valueSize value 

The code field identifies the type of information contained 
in the information packet. For example, a value of "1" 65 
indicates that the information packet contains a challenge. 
The identifier field contains the value (i.e., the round 
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indicator) that was generated at step 502. The length field 
identifies the length of the information packet. The value 
field contains the random number, or value of the challenge, 
generated in step 504. The valueSize identifies the size of the 
value field (e.g., 128 bits). 

In one or more embodiments, authentication messages are 
transmitted as key-value pairs in an ASCII string formal 
with each key-value pair separated by spaces and a carriage 
return signifying that there are no more key-value pairs. A 
key-value pair may be transmitted as a key (field name) 
followed by the equals sign ("«") followed by the value for 
that key (or field). For example, a key-value pair indicating 
a pseudo token may be "TYPE=pseudo" wherein the key is 
"TYPE" and the value for the key is "pseudo". Alternatively, 
the value may be javacard for a javacard token or mondex 
for a mondex card token. Such key-value pairs may be 
followed by a token identifier such as "ID = 
TOKENID343234234" wherein the key is "ID" and the 
value for the key is "TOKENID343234234". In one 
embodiment, if a space, equals sign ("="), or a new fine 
character needs to be transmitted, it is preceded by a 
backslash ("\") followed by three base-8 digits that repre- 
sents the character is ASCII. 

At step 508, authentication module 240 sends rendering 
commands to network terminal 202 prompting the user for 
the user's PIN. At step 510, authentication module 240 waits 
for a response from network terminal 202 or a timeout. 

If a timeout is detected at step 510, processing continues 
at step 514 to determine whether the maximum number of 
rounds has been exceeded. If not, processing continues at 
step 518 to increment the identifier and processing continues 
at step 504 to begin a new authentication round. If it is 
determined, at step 514, that the maximum number of 
rounds has occurred, processing continues at step 516 
wherein authentication module 240 sends rendering com- 
mands to network terminal 202 indicating a failure and the 
authentication process ends. Rendering commands can be, 
for example, part of a command protocol used to commu- 
nicate with network terminal 202 and its peripheral devices. 

A challenge routine includes commands sent by authen- 
tication module 240 to network terminal 202 to capture the 
PIN entry by the user and generates a response. Network 
terminal 202 generates a response value that is the output of 
a hash function (i.e., a hash value or challenge response) 
from an input including the user's PIN, the value of the 
identifier, the value of the secret stored in the user's smart 
card and the value of the challenge (e.g., the random number 
generated in step 504). 

A hash function can take variable-length input and con- 
vert it to a fixed-length output (a hash value). One example 
of a hash function takes the input and returns a byte 
consisting of the exclusive-or (XOR) of all the input bytes. 
There arc many other examples of hash functions that can 
used with embodiments of the invention. The hmac__md5 
function (RFC2104) is one example of a hashing function 
that is used in an embodiment of the invention to generate 
a response. 

The following packet format is used by network terminal 
202 to send the response to authentication module 240 
according to one embodiment of the invention: 
code identifier length valueSize value user ID 
The code field is set to a value of "2" which indicates that 
the information packet contains a challenge response. The 
value field contains the challenge response (e.g., the result of 
a hashing function). The userlD field contains the user's 
userlD. 

If authentication module 240 determines (at step 510) that 
it received a response from network terminal 202, process- 
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ing continues at step 512 to determine whether the identifier any name is typed into a login session, for example. Thus, 

returned by network terminal 202 matches the identifier the user only needs to provide an identification (e.g., used D) 

generated by authentication module 240. If so, processing or the terminal only needs to present a token. Consequently, 

continues at step 520 to examine the response returned by if the user provides a valid userid (which may be designated 

network terminal 202. 5 as any id or any token), the user is given access to the session 

At step 520, authentication module 240 determines that is associated with the userlD (or token). Such tokens 

whether the challenge response matches the response may be utilized to keep track of session to token mappings 

expected by authentication module 240. For example, so that if a user switches terminals, the appropriate session 

authentication module 240 can generate a hash value using to transmit to the terminal may be determined merely by 

its identifier, PIN, secret and challenge values. If the hash io checking the mapping. 

value generated by authentication module 240 matches the When the user disconnects from network terminal 202, 

challenge response generated by network terminal 202, authentication manager 204 or authentication modules 240 

authentication is partially successful. Authentication module is informed and informs session manager 206 of the discon- 

240 also verifies that the interconnection network address of nection. For example, when the user removes the smart card 

network terminal 202 and the user's userlD are valid. If the 15 from card reader 216, card reader 216 informs network 

challenge response, interconnection network address and terminal 202. Network terminal 202 informs authentication 

userlD are verified, authentication is successful. If not, manager 204 or authentication module 240 of the discon- 

authentication failed. nection. Authentication manager 204 (which may have been 

If authentication is successful, processing continues at informed by authentication module 240) informs session 

step 528 to send an N_AUTHENTICATE command. The 20 manager 206 that the user has disconnected from network 

format of the command, according to an embodiment of the terminal 202. Session manager 206 notifies each of the 

invention, is as follows: services in the user's session. 

code identifier length Challenge Routine 

The code field contains a value of "3" to indicate that the The authentication process can include a challenge initi- 

user was successfully authenticated. Processing continues at 25 ated by authentication module 240. FIG. 6 provides a 

step 530 to send rendering commands to network terminal challenge routine process flow for handling a challenge 

202 indicating that session manager 206 is connecting the according to an embodiment of the invention. The challenge 

user to one of the user's sessions. At step 532, authentication routine executes on network terminal 202 in response to a 

manager 204 notifies session manager 206 that the user is challenge command received from authentication module 

connected to the system via network terminal 202 and has 30 240. 

been authenticated for certain specified sessions. Authenti- At step 602, the key entry received from the user is read 

cation manager 204 sends the interconnection network until a return or enter key is pressed. The key entry is 

address of network terminal 202 and session manager 206' s translated to ASCII characters at step 604. At step 606, a 

sessionID to the server that is executing session manager hash function is used to generate a hash value, or challenge 

206 (i.e., the server identified in the sessionHost field of the 35 response, from the concatenation of the identifier, PIN, 

user's authentication database record) at step 532. secret, and challenge values. The challenge response is sent 

If authentication failed, processing continues at step 522 to authentication module 240 at step 608. At step 610, 

to send an N ^AUTHENTICATE command. Like a success- network terminal 202 awaits a response from authentication 

ful authentication, the N_AUTHENTICATE command module 240 or a timeout. If a response or a timeout occurs, 

includes a code field that indicates the status of the authen- 40 the challenge routine ends at step 614. 
tication process. A code value of "4" is used, for example to 

indicate that authentication failed. Processing continues at Network Terminal Initialization 

step 524 to send rendering commands to network terminal w , ( , . • , _ c a 

• j - L u \. . ■ r -i j j - • Network terminal 202 performs some initialization when 

202 mdicat.ng that the authentication failed and instructing fa flrs , turoed on whjle a ^ ^ nm ^ DtM 

the user to remove the smart card from card reader 216. 45 termina , 2Q2 nelwork (emjinal 2Q2 can ^ m a dorman , ^ 

^eauthenticauon process ends at step H6 if it is powered on. A user can awaken network terminal 202 

The process described with reference to FIGS. 5A-5B is c j * . * c .u * u ■ j -u j 

F , c , . . T . , from its dormant state using one of the techniques described 

one example of an authentication process. It should be . r , ,« . , , , . . 

f . . . . . • , . herein, for example. It should be apparent that other tech- 
apparent that other authentication techniques can be used , r , , , . , t - , 
... . r i • • m i . niques can be used to awaken nelwork terminal, 
with embodiments of the invention. In an alternate embodi- 50 

ment the user is not requested to enter a PIN. The user's card FIG - 3 P rovides a P rocess flow for ™«'«i«>«g nelwork 
in card reader 216 is enough to authenticate the user. The termmal 202 ln "*ponse lo a power up operation according 
userlD and secret value can be hashed with the identifier and 10 an embodiment of the invention. At step 302, a determi- 
ne challenge received from authentication module 240 to nat,on 15 made whether a P° wer U P °P cratl ° n ha s occurred, 
generate a response to a challenge by authentication module 55 If not ' Pressing continues to wait for a power up operation. 
240. In this way, a user can attach to the user's services At ste P 304 - a re£ l uest 15 gyrated by network terminal 202 
simply by inserting a card containing valid information into l ° the mwo± 10 ,esl * e " etwork connection. At step 306 
card reader 202 a determination is made whether a response is received. If 
Further, it should be apparent that embodiments of the not > Processing continues at step 310 to generate an error and 
invention can be used wherein no authentication of a user is 60 Processing continues at step 302 to await a power up 
performed. For example, in a trusted or secure environment operation. 

there may be no need to verify the authenticity of a user. In If il is determined, at step 306, that an answer is received, 

one or more embodiments of the invention, a user is con- processing continues at step 308 to send an acknowledge (an 

nected to a session only after being authenticated by authen- ACK) message and initialization of network terminal 202 

tication manager 204 or authentication modules 240. In such 65 can continue at step 402 of FIG. 4A. 

an embodiment, an authentication module 240 may authen- FIGS. 4A-4C provide a process flow according to an 

ticate all users merely when presented with a token or when embodiment of the invention for initializing network termi- 
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nal 202 in response to an awaken operation. Referring to waiting_for_startup variable is set to no (i.e., "N"). Pro- 

FIG. 4A, network terminal 202 waits for notification of the cessing continues at step 440 to process the challenge 

awaken operation. In an embodiment of the invention, the request at steps 440 and 442. The challenge request can be 

awaken operation is the insertion of a user's smart card in handled as described above with reference to FIGS. 5A-5B 

card reader 216. 5 and 6, for example. 

If it is determined that a smart card is inserted in card If it is determined, at step 434, that network terminal 202 

reader 216, processing continues at step 404 to send a is not waiting for a response to a startup request, processing 

request to obtain the interconnection network addresses of continues at steps 440 and 442 to handle the message (e.g., 

authentication manager 204 and network terminal 202. rendering commands to display output generated by service 

Alternatively, a user's smart card can be preprogrammed 30 234). 

with the interconnection network addresses. Network termi- At step 444, a determination is made whether the user has 

nal 202 can read the interconnection network addresses from removed the smart card from card reader 21 6. When the user 

the smart card via card reader 216, for example. In one or removes the card from card reader 216, network terminal 

more embodiments, a user's home server (or preferred 202 sends a disconnect message to authentication manager 

server) is preprogrammed into a user's smart card. ^ 204 (or the appropriate authentication module 240) at step 

Consequently, if a user is working on a remote network, the 443. Network terminal 202 waits for an acknowledgment 

user may still connect to the user's home server with the (ACK) message from authentication manager 204 (or 

ability to utilize services associated with that server (that authentication module 240). When the ACK message is 

may not be available or available to the user on the remote received, network terminal 202 clears the screen, at step 450, 

network). 20 anc j returns to step 402 to wait for another user to insert a 

At step 406, network terminal 202 awaits a response or a smart card in card reader 216. 

timeout. If a timeout occurs, processing continues at step if j t ^ determined, at step 444, that the user has not 

412 to determine whether the maximum number of tries has removed the card from card reader 216, processing contin- 

been exceeded. If the maximum number of tries has been ues at step 446 to determine whether network terminal is 

exceeded, processing continues at step 410 to generate an waiting for a response to its startup request. If so, processing 

error. If the maximum number of tries has not been continues at step 422 to determine whether a response has 

exceeded, processing continues at step 414 to increment the been received. If network terminal is not waiting for a 

number of tries and processing continues at step 404 to response from a startup request, processing continues at 

resend the request for the interconnection network ste p S 440 and 442 to process any messages sent to network 

addresses. terminal 202. 

When a response to the request is received, processing 

continues at step 408 to send an ACK. Processing continues Message Format 

at step 416 of FIG. 4B. At step 416, network terminal 202 . , , - iL 

. t ^ . t *u *■ *- -ia>* a. In an embodiment of the invention, a connection to 

sends a startup request to authentication manager 204. At . . . . , , . , . . 

Ato . .* • . • u- u 1 * • 1 mi 35 network terminal 202 is established via a user datagram 

step 418, a retry time is set in which network terminal 202 . , /T T ~ m t ™ 4 . . . ? Tr> „ 

c . *i_ * ^ *■ a a a protocol (UDP) port. That is, packets are sent via a UDP 

waits for a response to the startup request. At step 420, a r . i > , j • • n^r. ™ 

. . , . /. ... t t . 4 * 1 , 1 - n - . connection and received at a destination UDP port. The 

variable is set to indicate that network terminal 202 is , . . . c t , * 

... r * *u . - , jl . , destination UDP port uniquely identifies the connection, 

waiting for a response to the startup request. At step 422, ™ . 1 i_ j \. 1 • / j JL . 

1 . • 1 mi •* c Packet length and checksum information are provided by the 

network terminal 202 waits for a response to the startup An T TrNT , , f ™ «. . n < • t- 1_ . w ■ 

t t , 4 , r 40 UDP header. Buffer size fits in an Ethernet Maximum 

request. While network terminal 202 awaits a response, „ P TT . ., uro/Iinn , , ~ , . 

t . . , ' Transfer Unit (MTU) with IP/UDP headers. Data is sent over 

authentication manager 204 may present the message to one iL A * a * \ 

or more authentication modules 240 to determine if one or the network in Qetwork order ( bl g' endian )- 

more modules desires to take responsibility for the request. h should be a PP arcnt that other protocols can be used in 

If it is determined that a response is not received, pro- 45 ^ of U A D , P ^ r f X ^P le ' Protocolssuch asan ATM AAL5 

cessing continues at step 424 to determine whether the retry (AAL or AI M Adaptation Layer) can be used. 

time as been exceeded. If not, processing continues at step T^ 5 ' a method and apparatus for session management 

422 to wait for a response. If the retry time has been and user authentication has been described. Particular 

exceeded, processing continues at step 426 to determine embodiments described herein are illustrative only and 

whether the maximum number of tries has been exceeded. If 50 should DOt lknit the P resent ™™ {ion thereby. The invention 

not, processing continues at step 428 to generate an error and 15 defi ° ed by &c claims and their full scope of equivalents. 

return to step 416 to resend the startup request. If not, What ^ claimed is: 

processing continues at step 430 to increment the number of L A . svstem for controlling access by a user to sessions, 

tries and reset the retry time. At step 432, the startup request comprising: 

is resent and processing continues at step 444 to determine 55 an authentication manager for obtaining an authentication 

whether the card has been removed from card reader 216. request from said user, wherein said authentication 

If it is determined, at step 422, that a response was request comprises at least one of a token and a pseudo 

received, processing continues at step 434 of FIG. 4C. At token; 

step 434, network terminal 202 examines the variable ini- a plurality of authentication modules for authenticating 

tially set in step 420 to determine whether it is waiting for 60 said user, wherein said plurality authentication modules 

a response to the startup request. If so, processing continues are distinct from said authentication manager and 

at step 436 to determine whether the response is a challenge wherein said plurality authentication modules are not 

message (e.g., by an authentication module). If not, process- input devices; and 

ing continues at step 424 to repeat the startup request if the a session manager for obtaining notification of authenti- 

maximum number of tries has not been exceeded. If it is 65 cation from said plurality of authentication modules, 

determined, at step 436, that a challenge message has been 2. The system of claim 1, wherein said plurality of 

received, processing continues at step 438 to set the authentication modules comprise an authentication module 
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configured to only accept a connection with said user if said 
user has said token. 

3. The system of claim 1, wherein said plurality of 
authentication modules comprise an authentication module 
configured to only accept a connection with said user if said 5 
user has said pseudo token. 

4. The system of claim 1, wherein said plurality of 
authentication modules comprise a first authentication mod- 
ule for accepting users with tokens and a second authenti- 
cation module for accepting users with pseudo tokens. 10 

5. The system of claim 1, wherein said plurality of 
authentication modules comprise a third authentication 
module for accepting all users. 

6. The system of claim 1, wherein said pseudo token 
comprises at least one of an Ethernet address and a media 15 
access controller address. 

7. The system of claim 1, wherein said authentication 
request comprises an ordered ASCII string and wherein said 
ordered ASCII string comprises a token type indication. 

8. A system for controlling access by a user to sessions, 20 
comprising: 

an authentication manager for obtaining an authentication 
request from said user; 

first and second authentication modules for authenticating 
said user, wherein said first and second authentication 25 
modules are distinct from said authentication manager, 
wherein said first and second authentication modules 
are not input devices, wherein said first authentication 
module is configured to accept said authentication 
request if said authentication request is registered with 30 
the system, and wherein said second authentication 
module is configured to accept all authentication 
requests; and 

a session manager for obtaining notification of authenti- 35 
cation from said first and second authentication mod- 
ules. 

9. The system of claim 8, wherein said authentication 
manager is configured to present said authentication request 
only to said first authentication module. 4Q 

10. The system of claim 9, wherein said first authentica- 
tion module is configured to present said authentication 
request to said second authentication module. 

U. The system of claim 10, wherein said first authenti- 
cation module is configured to present said authentication 45 
request to said second authentication module if said first 
authentication module does not want to accept responsibility 
for said authentication request. 

12. The system of claim 8, wherein said authentication 
request is presented to said second authentication module 5Q 
only if said authentication request is not registered with the 
system. 
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13. The system of claim 8, wherein said second authen- 
tication module can register said authentication request with 
the system. 

14. A system for controlling access by a user to sessions, 
comprising: 

an authentication manager for obtaining an authentication 
request from said user; 

an authentication module for authenticating said user, 
wherein said authentication module is distinct from 
said authentication manager, wherein said authentica- 
tion module is not an input device, and wherein said 
authentication manager is configured to present said 
authentication request to said authentication module; 
and 

a session manager for obtaining notification of authenti- 
cation from said authentication module, wherein said 
authentication manager is configured to provide said 
authentication module with a start session service for 
ensuring that a session is started. 

15. The system of claim 14, wherein said authentication 
module comprises a plurality of cascaded authentication 
modules, wherein each of said plurality of cascaded authen- 
tication module is configured to accept responsibility for a 
particular type of authentication request, and wherein said 
authentication request is presented from one cascaded 
authentication module to another until said authentication 
request is presented to a cascaded authentication module that 
can accept responsibility for said authentication request. 

16. The system of claim 15, wherein at least one of said 
cascaded authentication modules is configured to revoke 
said authentication request. 

17. The system of claim 15, wherein at least one of said 
cascaded authentication modules is configured to request a 
first password from said user and a second password from 
said user. 

18. The system of claim 15, wherein at least one of said 
cascaded modules is configured to accept responsibility for 
an authentication request based on biometric data. 

19. The system of claim 15, wherein at least one of said 
cascaded authentication modules is configured to accept 
responsibility for an authentication request based on a smart 
card. 

20. The system of claim 15, wherein at least one of said 
cascaded authentication modules is configured to authenti- 
cate said authentication request for a specified period of 
time. 

21. The system of claim 14, wherein said authentication 
manager, said authentication module, and said session man- 
ager are configured using a computer readable program 
code. 

***** 
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